Supporting Systems Engineering with Methods and Tools: A Case Study

Many projects have applied the Hatley-Pirbhai real-time structured analysis method to the definition and analysis of system/software requirements. Application of the method results in the generation of a functional requirements model, which includes data/control flow diagrams, plus process and control specifications. Although infrequently applied, the method also defines an architecture model, which specifies the physical components and the physical interconnect channels for the system. After first providing a brief overview of the architecture and requirements models, we discuss how the HatleyPirbhai methodology is being used by system engineers on a real-time embedded avionics program. We also discuss the set of automated tools used to support the methods, and how both methods and tools were tailored and enhanced. Lastly, we describe operational experience and some difficult lessons learned. 1. Hatley-Pirbhai methodology Structured analysis techniques were developed in the 1970’s to improve the system specification process. The techniques are based on the idea that systems can be more clearly and easily described by using pictures rather than words. Derek Hatley and Imtiaz Pirbhai [1] have built on the work performed by Edward Yourdon [2], Tom DeMarco [3] and others to develop a comprehensive method for specifying real-time systems. The Hatley-Pirbhai methodology (HPM) separates the system specification into two models: requirements and architecture. The requirements model describes what the system is supposed to do, while the architecture model describes the physical entities in the system and the allocation of requirements to these entities. Examples of HPM diagrams for both requirements and architecture models are provided in Figure 1. Requirements model. The requirements model combines traditional structured analysis and finite state modeling techniques to define the system function. Data flow diagrams (DFDs), process specs, and a dictionary are all borrowed directly from structured analysis. HPM adds control flow diagrams and control specs to structured analysis to specify the systems finite state behavior. Control specs use traditional finite state elements such as decision tables and state transition diagrams. In addition, HPM introduces the concept of enhancing requirements. The core requirements of the system which are independent of specific technology are captured in the core model. These requirements are then enhanced to add requirements for input, output, user interface and maintenance/self test processing. The goal is to isolate the core model from the technology dependent aspects of the system which are more likely to change as technology advances. An architecture template provides separate regions for each of the four categories of enhanced requirements. Architecture model. The architecture model is adapted from functional block diagrams and describes the physical partitioning of the system. The architecture context diagram (ACD) shows the physical boundaries of the system. The architecture flow diagram (AFD), shows the physical entities, called modules, in the system. An architecture module may be a system, subsystem, unit, unit module, component, etc., depending on the level of detail of the model. The architecture flows on the AFD show the transfer of information between modules. The interconnection of modules in the system is shown on the architecture interconnect diagram (AID). The physical channels through which the information passes between modules are shown as architecture interconnects. Architecture interconnects may be electrical wires, busses, waveguide, mechanical connections, or any physical channels used in the system. The type of line used to represent an interconnect depicts the type of channel. The AFDs and AIDs are pairs of diagrams each showing the same modules. Also, the architecture flows and interconnects are included in the dictionary. Dictionary entries identify the allocation of data flows to architecture flows as well as the allocation of architecture flows to interconnects. The connection between the architecture and requirements models is achieved via a traceability matrix with the help of superbubbles. The system engineer decides what functionality will be accomplished by each module and assigns the requirements accordingly. To assist in this pro-